10. Security Considerations
For servers using the token approach for authentication, the token should be considered private. A client should take steps to safeguard the token. The token approach isn’t perfect security; a token could become more widely distributed than intended or anticipated.
Servers SHOULD
provide a means for token values to be automatically or manually expired. Services SHOULD
consider obfuscating the userid
in a Freebusy URL. A service SHOULD
prevent a client from probing for valid userid
s which might reveal private information about users such as their email address. A server MAY
return an HTTP 404 error rather than an HTTP 403 error when the requester does not have permission to view the Freebusy information of the requested user.
Servers MAY
support HTTP Authentication IETF RFC 2616 for access to the Freebusy URL content.
HTTP protocol transactions are sent in the clear over the network unless protection from snooping is negotiated. This can be accomplished by use of TLS, as defined in IETF RFC 2818. In particular, HTTP Basic authentication, as defined in IETF RFC 2616, MUST NOT
be used unless TLS is in effect.
Servers MUST
take adequate precautions to ensure that clients cannot consume excessive server resources (CPU, memory, disk, etc.) through intentionally malicious requests. For example, a request may be made for an inappropriate amount of time, e.g. 100 years. A server is free to fail such a request.
When rolling up Freebusy information, more information than necessary about a user’s events is exposed if busy periods overlap or are adjacent (this tells the client requesting the Freebusy information that the calendar owner has at least two events, rather than knowing only that the calendar owner has one or more events during the busy period).
Thus, a conservative approach to calendar data privacy would have servers always coalesce such busy periods when they are the same type. Security considerations described in iCalendar IETF RFC 2445 and iTIP IETF RFC 2446 are also applicable.